Features
What is a "feature?"A feature is a new function or series of functions within an application which did not previously exist. On this page you will find changelogs associated to features being delivered in incremental pieces. Each changelog describes a small function delivered to support the larger feature function as a whole. Below you will find a list of features, with their respective changes, associated to the Expere Document Services version the feature is or will be delivered.
What is the impact on users?
If you have a scenario in which duplicate data exists when XPath 1.0 Compatibility Mode is disabled, any transactions may fail. Depending on the root cause of the failure, you may need to update your data mapping or deploy an updated content library.
Wolters Kluwer has been and will continue to monitor logs and reach out to customers to let them know of the specific scenario that will fail when XPath 1.0 Compatibility Mode is turned off.
XPath 1.0 Compatibility Mode
XPath Compatibility is a function that evaluates the transaction and logic within Expere .REQ files (Requirements files that comprise Wolters Kluwer content) during document generation. Users can leverage the current rule processing logic to determine whether to specify a specific instance of a datapoint within a collection container. If so, this results in always using the first instance of the value, specifically if duplicate data in a transaction exists . This could happen as a result of duplicate data in the transaction or the PTR logic not specifying the specific instance to use. Our internal log files can identify when XPath 1.0 Compatibility mode logic is triggered.
When will this change occur? Wolters Kluwer recognizes the dynamic nature of this enhancement due to regular content updates, and regulation changes and application improvements impacting users’ front-end systems. We wanted to provide adequate lead time so you can prepare for this change.
This change will be implemented with our standard deployments:
Customer Test Environment: Fall 2024 / Q4 2024
Production Environment: Fall 2024 / Q4 2024
Fillable Field Default Behavior Change
Effective Date for Hosted Expere users:
- Customer Test Environment: July 2024
- Production Environment: August 2024
Effective Date for self-hosted Expere users:
- 2024 Release Two
Expere’s behavior has been updated to generate Fillable Fields when specified rather than producing them by default. These changes simplify the logic and makes Expere more maintainable.
The current default allows documents to support fillable fields but not eSignature fields. The new behavior will support fillable fields when eSignatureAndFieldSupport options are specified in the request; otherwise, fillable fields will not be generated on the documents
There are two types of fields that can be added to the generated documents.
- Acroform fields (referred to as “fillable fields”) can contain user-entered data for editing a document after it has been generated and output by Expere.
- Electronic Signature fields (eSignature) are used to populate signature names, dates, or initials.
The ability to control these fields is based on data passed in the API Request from the Loan Origination System (LOS) integration to Expere.
User action and impacts
The com.bankerssystems.expere.render.acroformSupport property ONLY
supports a "false" value.
No user action is required provided that fillable fields are not needed unless the eSignatureAndFieldSupport ancillary output is specified. To return fillable fields without eSignature fields (the current default behavior), the following eSignatureAndFieldSupport ancillary output options should be specified:
- eSignatureAndFieldSupport = true
- eSignatureCoordinatesOnly = true and
- NonSignatureFieldCoordinatesOnly = false
These ancillary options are currently available and can be utilized at any time. If the desire is to have documents with no fillable fields nor eSignature fields, no further action is required.
Multiple notes supported for commercial transactions
Expere now supports a single transaction with multiple promissory notes for the Commercial line of business.
FOP 2.8 upgrade
Expere uses Apache™ FOP (Formatting Objects Processor) to generate PDF documents. Currently, the Expere Engine supports two FOP versions: 1.1 and 2.8.
- Expere uses version 1.1 to generate standard PDF documents and is the default rendering engine.
- Expere uses version 2.8 to generate Web Content Accessibility Guidelines (WCAG) compatible Tagged PDF documents.
Scheduled for March 2024, Expere will use FOP 2.8 to generate both standard PDF and Tagged PDF documents.
What do you need to do?
If you want to test or use FOP 2.8 before March 2024, contact your Project Manager or your Account Executive to request a Content URI be set up and configured to use FOP 2.8. Let them know what content and environment (Customer Test or Production) you want to be configured.
- Once you have the Content URI, change your application to use this new Content URI, as you would with any other content update.
Otherwise, you can wait until we enable FOP 2.8 for all customers in March 2024.
What is changing?
With the upgrade to FOP 2.8, you can expect to see the following:
- Minor document generation performance improvement.
- Transaction barcodes are no longer bolded and now honor case-sensitive values.
- Transaction barcode height will be supported in the September and October Hosted Expere release.
- For single page documents containing Header and Footer notices, Wolters Kluwer-authored source content files (REQs) must include a "FirstPage" attribute when document logic dictates different Header and Footer requirements per page.
- For single page documents containing specific margin requirements, Requirements Editor files must include "InstanceFirstPage...Margin" and a corresponding value when document margin logic dictates different Margins per page.
- REQs using the Integrated Disclosure Stylesheet no longer produce barcodes when not specified to do so.
Augment Transaction
During the course of the content authoring process, a new Augment Transaction
REQ file is available for authoring. Expere can update, or "augment" an incoming
request if the transaction contains an /txn/AugmentTransactionInd =
true element and value. When this value is provided, Expere resolves
the XPath(s) in the related line of business Augment Transaction file based on the
transaction XML and sets the XPath(s) in the transaction. Remaining autoselection
logic is employed and documents are generated.
Support Embedded PDF
Expere support an authoring format, Embedded PDF, that has an imported PDF file in the content file (.REQ file). This .REQ type allows user to import (“embed”) a tagged PDF and specify fields (checkbox or test) as fillable or not. Embedded PDF documents also can be configured to be electronically signed if desired.
SmartSign +
We have enhanced Expere to now integrate with the eOriginal SmartSign®+ solution.
Document List
When a package is created, Expere creates a list of documents included in that
package, the names of which are derived from the
InstanceDisplayName within the document .REQ file. The REQ file
properties file specifies that a full document list should be created within the
document that is selected, such as the Closing Instructions
(ClosingInstructions.req)
Partial Document List
When a package is created, Expere creates a list of documents included in that
package, the names of which are derived from the
InstanceDisplayName within the document .REQ file. Wolters
Kluwer has enhanced Expere to now support the creation of a "partial" document
lists." Expere users may now select the specific documents to be included in this
partial document list.
SMART Doc 1.02
Wolters Kluwer enhanced Expere to generate MISMO SMART Doc version 1.02. A MISMO SMART Doc is an electronic document that meets specified standards set forth by the Mortgage Industry Standards Maintenance Organization (MISMO). SMART is an acronym that stands for Securable, Manageable, Archivable, Retrievable, and Transferable. The MISMO SMART Doc is the industry standard for eNotes. The SMART Doc format links the visual representation or text of the note along with data included in the note and the signature. They can be viewed using a variety of technologies, most commonly PDF, and they are electronically sealed to prevent tampering. This format ensures that what a borrower signs on their computer screen is the exact document that will be stored. Once an eNote is signed, it is transferred to an electronic vault or eVault where the original file is securely stored and where it can be transferred to another eVault as needed.
WCAG 2.0
In an ongoing effort to make Expere base content screen reader accessible, compatible with WCAG 2.0 as verified by the Adobe Acrobat DC accessibility checker, Wolters Kluwer has conducted an exhaustive effort to audit, update, and test Expere base content. As a result, we have implemented numerous enhancements to our existing content library to make them WCAG 2.0-compatible.
eOriginal: native Expere eNote files
Expere integrated users can utilize Expere to create and upload dynamic eNote files to eOriginal.
Callback to Salesforce
Wolters Kluwer has enhanced callback functionality to utilize Salesforce using token authorization. For more information, see Callback to Salesforce feature, Callback, and Callback Authorization.
Hosted Expere > Wolters Kluwer ESign Delivery
Wolters Kluwer has integrated Hosted Expere and Wolters Kluwer ESign (WKES) in order to utilize the latter's delivery options. For more information, consult the Hosted Expere > Wolters Kluwer E-Sign Feature Guide.